1. Field of the Invention
This invention relates in general to computer-implemented database systems, and, in particular, to architecting the flow of built-in functions to enhance performance during runtime in a database system.
2. Description of the Related Art
Databases are computerized information storage and retrieval systems. A Relational Database Management System (RDBMS) is a database management system (DBMS) which uses relational techniques for storing and retrieving data. Relational databases are organized into tables which consist of rows and columns of data. The rows are formally called tuples. A database will typically have many tables and each table will typically have multiple tuples and multiple columns. The tables are typically stored on direct access storage devices (DASD), such as magnetic or optical disk drives for semi-permanent storage.
Processing information, e.g. user applied queries, in database systems through the execution of various functions used to be much simpler. In the past, only a few simple functions existed. Thus, all of the functions could be contained within a single module, a single logical location, for execution.
Over time, a larger number of database functions have been implemented and the functions have become more complex. In addition, databases have been taking on a greater burden by implicitly casting and converting between different data type formats. As a result, the number of functions and the cumulative size and complexity of these new functions have overflowed the simple module design. Thus, it is desirable to split the functions amongst multiple modules. This is so because, if at run time a function must be selected from a single large list of possible functions, i.e. in a single module, it becomes unwieldy to traverse the entire list each time a function must be executed. Thus, having a single module is not practical. However, a multiple module structure also has drawbacks, as module calls are resource expensive.
Each time a module is called, a great number of instructions must be executed to set up a new stack area, new data area, etc. Due to the large number of functions, there are a large number of modules, even if functions are broken up into units based on related types or classes. However, in order to be efficient at run time, there is a need to limit the number of module calls. The key is to properly define the units of work, the modules, which include not only the functions themselves, but also related operations, e.g. checking for nullity of data, encoding/decoding the function, etc.
While past systems have defined modules to handle a specific class type, there has been no optimization directed to holding module scope as long as possible. By holding module scope as long as possible, two goals are accomplished. First, there is a reduction in the number of expensive module calls. Second, the scope, or number, of functions examined within each module is reduced, which reduces processing effort.
Therefore, there is a need in the art for techniques that more efficiently execute built-in functions by holding module scope as long as possible.